Team Geek

2013

Brian Fitzpatrick

Googleのシカゴエンジニアリングオフィスの共同創設者であり、Googleのオープンデータの思想的リーダー兼社内アドバイザーである。

Ben Collins-Sussman

Googleのシカゴエンジニアリングオフィスの共同創設者であり、SubversionのGoogleのBigTableプラットフォームへの移植を担当した。

複数のプログラマが関わる場合、優れたコードを書くだけではプロジェクトは成功しない。全員が最終目標に向かって協力することが重要であり、チームの協力はプロジェクト成功のカギとなる。

目次

1章　天才プログラマの神話

1.1　コードを隠して

1.2　天才の神話

1.3　隠したらダメになる

1.4　チームがすべて

1.5　三本柱

1.6.1　エゴをなくす

1.7.2　学習のための時間を残す

1.7.4　影響を受けやすくする

1.8　次のステップ

2章　素晴しいチーム文化を作る

2.1　文化とは何か

2.2　なぜ気にかける必要があるのか？

2.3　文化と人々

2.4　成功する文化のコミュニケーションパターン

2.5　ハイレベルの同期

2.5.1　ミッションステートメント（いや、マジで）

2.5.2　効率的なミーティング

2.5.3　「地理的障害」のあるチームで働く

2.5.4　設計文書

2.6　日常的な議論

2.6.1　メーリングリスト

2.6.2　オンラインチャット

2.7　課題管理ツールを使う

2.8　エンジニアリングとしてのコミュニケーション

2.8.1　コードコメント

2.8.2　ソースコードに名前を書く（別名：「Authorタグ」問題）

2.8.3　すべてのコミットにコードレビュー

2.8.4　リアルなテストとリリースプロセス

2.9　すべてはコードに通ず

3章　船にはキャプテンが必要

3.1　自然は真空を嫌う

3.2　@Deprecatedマネージャー

3.2.1　「リーダー」は新しい「マネージャー」

3.2.2　1つだけ怖いのは ……まあ、全部だ

3.3　サーバントリーダー

3.4　アンチパターン

3.4.5　アンチパターン：採用を妥協する

3.4.6　アンチパターン：チームを子どもとして扱う

3.5.1　エゴをなくす

3.5.2　禅マスターになる

3.5.3　触媒になる

3.5.4　先生やメンターになる

3.5.5　目標を明確にする

3.5.6　正直になる

3.5.7　幸せを追い求める

3.5.8　その他のヒントやトリック

3.6　人は植物

3.7　内発的動機と外発的動機

3.8　最後に

4.1　「有害」の定義

4.2　チームを強化する

4.3　脅威を特定する

4.3.1　他人の時間を尊重しない

4.3.3　権利を与えすぎる

4.3.4　未熟なコミュニケーションと複雑なコミュニケーション

4.3.5　パラノイア

4.4　有害な人を追い出す

4.4.1　完ぺき主義者には別の方向性を示す

4.4.2　生命体にエサを与えない

4.4.3　感情的にならない

4.4.4　不機嫌の真実を探せ

4.4.6　諦めるときを知る

4.4.7　長期的に考える

4.5　最後に

5章　組織的操作の技法

5.1　善玉、悪玉、戦略漢

5.2　理想：チームがうまく機能している会社

5.3　現実：環境が成功の邪魔になっているとき

5.3.1　悪いマネージャー

5.3.2　オフィスの政治家

5.3.3　悪い組織

5.4　組織を操作する

5.4.1　許可を求めるより寛容を求めるほうが簡単

5.4.2　道がないなら道を作る

5.4.4　運と親切の経済

5.4.6　強力な友達を探す

5.4.7　忙しい経営者に（メールで）お願いする方法

5.6　希望は残されている

6章　ユーザーも人間

6.1　一般認識を管理する

6.1.1　第一印象に注目する

6.1.3　業界のアナリストと付き合う

6.2　君のソフトウェアはどれだけ使いやすいだろうか？

6.3　ユーザーとの関係を管理する

6.3.1　見下さない

6.3.2　我慢する

6.3.3　信頼と喜びを作る

6.4　ユーザーのことを忘れない

付録 1　エピローグ

付録 2　あわせて読みたい